Point-of-sale scanners that read machine readable codes (e.g., barcodes and digital watermarks) from packaged retail products using 2D imaging sensors, are now commonly found in supermarkets and other retail establishments. When such a scanner captures an image of a machine readable code, it commonly decodes a “GTIN” (Global Trade Item Number) payload, performs some data checking, and then outputs the GTIN to a serial port (or USB port) for transmission to an associated point-of-sale (POS) terminal.
The functionality of such a scanner is established by firmware store in device memory. The firmware is typically produced by the scanner manufacturer (e.g., Company S—for scanner), and may include components provided from outside companies. One such component may be software for decoding steganographic digital watermarks (software provided by Company W—for watermark), which are encoded in the artwork of product packaging and convey product GTINs.
In an exemplary development cycle for a scanner, Company S designs a new product offering, and provides associated hardware and software specifications (e.g., image size, frame rate, image data format, API calls, etc., etc.) to companies who will be providing software components to be included with the scanner. Company W sends the latest version of its watermark decoding software to Company S, along with configuration instructions that customize the software for the hardware-specific parameters. Such software is commonly provided as a Software Development Kit (SDK), which can include source code instructions (e.g., in C++), required code libraries, and other software development tools.
Company S performs a “build” process in which the watermark SDK, the configuration data, and other software modules and data (including software authored by Company S), are compiled together into firmware code, which is loaded into beta versions of the new hardware platform by testing—including testing by Company W. As feedback from the testing is generated, Companies S and W modify their respective software/configuration data, and the cycle repeats.
While seemingly straightforward, this process is prone to confusion in actual practice. Due to typically-tight product development deadlines, things are done in a hurry. Company S may issue several new builds of its firmware each week. As testing progresses, Company W may modify its configuration instructions on a similar schedule, with occasional updates to its SDK. In the rush, Thursday's build of the scanner firmware may include Tuesday's revision of the watermark configuration instructions—while Wednesday's revision waits in a still-unopened email in the Inbox of a Company S developer. Or the Thursday build of the firmware may employ last week's version of the watermarking SDK, while a newer SDK release that was delivered Wednesday was saved into a wrong directory and is overlooked at build time.
The build process performed by Company S commonly involves proprietary tools and software that Company S does not share with others (e.g., Company W). As a consequence, the build process cannot be replicated or verified by Company W.
The various versions of firmware resulting from this process can be stews of uncertain ingredients.
This uncertainty about what version of Company W's SDK was used in a particular build of the firmware, and which set of Company W's configuration data was employed, makes troubleshooting difficult. If the scanner—with the latest firmware loaded—does not behave as expected, Company W naturally assumes it was built with the SDK and configuration data that was most-recently delivered to Company S. (Company S may say so, too, incorrectly.) But this assumption may be wrong. This problem can lead Company W to focus on a certain piece of code, or a particular item of configuration data, as the potential source of a troublesome behavior when, in fact, the suspect code/configuration data was not even included in the build being tested. Much frustration can result. And, as a consequence, delivery of the finished scanner product to commercial customers can be delayed.
To try and address this problem, Company S could design the hardware with the capacity to output version data for included software components and configuration instructions—either via the serial data port through which item identification codes are normally sent to the associated point-of-sale terminal, or via an administrative data port specialized for diagnostic and other control data. Company W could then modify its SDK to send version information, for the watermark SDK and for the configuration data, to such an output port each time the scanner is booted, thereby resolving the noted uncertainties about what components were included in a particular firmware build.
Unfortunately, such a solution may introduce as many difficulties as it solves.
There is no standardization as to the design or use of such an output port to provide debug information. And there is not just one Company S; there are multiple competing scanner companies: Company S1, Company S2, Company S3, etc. If scanners of Company S1 have the capacity to output debug information, their software requirements for this functionality—and often their associated hardware designs—will likely be different than counterpart software requirements/hardware designs included in scanners of Company S2. Moreover, even within different scanner offerings of a single company, the hardware or software protocols associated with outputting debug information may be different. This can require Company W to write special code tailored to the hardware and software requirements for each company's scanners (and sometimes for each scanner model of each company)—customized to the parameters of the output port (if present) and its communication protocols. Still further, Company W may not even have access to the output port; that port may be managed exclusively by software from Company S, and intended only for its use.
If such an arrangement were practical, it would increase the development and testing burden on Company W. It would also proliferate different variants of software—increasing the risk that an SDK sent for use with a particular scanner company may be incompatible. (And with more variants of software come more opportunities for bugs to creep in.)
One aspect of the present technology concerns getting debug information from a scanner, even without control over the scanner's output port(s). This is done, in a particular embodiment, by reading chunks of diagnostic data from a scanner memory, and formatting them to appear as GTIN identifiers, for outputting by the scanner. GTINs created for this purpose of conveying debug information from the scanner are termed “faux GTINs” in this specification. This debug reporting mechanism can be activated by presenting a special machine readable code (a “trigger code”) to the scanner.
The prior art teaches that a special barcode can be presented to a scanner to enter configuration data or instructions into a scanner. For example, U.S. Pat. No. 5,929,418 teaches that a scanner can be reprogrammed by reading special barcodes from a printed booklet. U.S. Pat. No. 5,756,981 similarly teaches that a scanner CPU can be placed in a “programming” mode by detection of a special barcode. U.S. Pat. No. 8,317,105 teaches that a special bar code can be presented to a scanner to unlock certain functionality, such as decoding of certain symbologies. Such patents, however, do not teach the opposite process—getting information out of a scanner.
Nor is the prior art understood to teach or suggest altering diagnostic data so that it appears as a faux GTIN.
Outputting GTINs is the basic function that retail scanners exist to perform. GTINs output by a scanner form a one-way communication channel—a channel that is reliably present in all scanners. Aspects of the present technology employ this primary scanner functionality as a communications channel to output debug information, without requiring specialized knowledge about the make, model or hardware configuration of the scanner, nor control over its output port(s).
In another aspect of the present technology, Applicant recognized a particular problem with this approach of altering debug information to form faux GTIN codes, namely duplicate detection logic found in scanner software. Such logic is provided to ensure that a shopper is charged only once for an item, even if the item may be depicted in multiple sequential frames captured by the scanner, from which the same machine readable code is multiply-decoded. Such logic commonly notes each payload that is output to the POS terminal, and starts a duplicate detection timer (e.g., 1 second). If the same payload is again decoded within the timer interval, the scanner prevents that repeated payload from being reported again to the POS terminal.
Depending on the nature of diagnostic data to be output, two or more sequential faux GTINs may convey the same information. (Consider, e.g., a long string of zeroes in the diagnostic memory.) Accordingly, another aspect of the present technology involves ensuring that identical chunks of data read from the diagnostic memory are not conveyed by identical faux GTINs (which might be filtered by the duplicate detection logic).
The foregoing and other features and advantages of the present technology will be further apparent from the following detailed description, which proceeds with reference to the accompanying drawings.